Signed Query
Trusted Document の一例
スタディサプリ の開発チームによる実装パターン: https://blog.studysapuri.jp/entry/2024/04/15/100000
Persisted Query のように、サーバに ホワイトリスト 的にクエリを事前に登録するのではなく、共通鍵暗号方式 を用いてクエリの信頼性を検証する方式
具体的なフロー
https://cdn-ak.f.st-hatena.com/images/fotolife/Y/YutaUra/20240328/20240328184823.png
https://blog.studysapuri.jp/entry/2024/04/15/100000
1. クライアントをビルドする際に、GraphQL-Codegen などのツールを利用してクライアントアプリで利用しているクエリをまとめ、それぞれの HMAC を計算し、クライアントアプリケーションに埋め込む
2. クライアントは、クエリとそれに対応した HMAC をサーバに送信する
code:json
{
"query": "query Home { ...}", // query is needed for Signed Query
"operationName": "Home",
"variables": {},
"extensions": {
"signedQuery": {
"signature": "xxxxxxxxxx"
}
}
}
3. サーバは、あらかじめ共有されていた 共通鍵 を用いて HMAC を検証することで信頼されたクエリか判断 し、実行する
信頼されていないクエリの場合、エラーを返す
メリット
一度 共通鍵 を共有できる状態を構築できれば、Persisted Query と比較して事前にクエリを GraphQL サーバに登録する手間が無くなる
これにより、クエリの 信頼性 を担保しつつクライアントアプリをいつでもアプリケーションできる状態に
warning.icon 共通鍵 の管理は十分注意が必要
e.g. AWS Secrets Manager に鍵を保存し、ビルド時のみ参照するようにする
#GraphQL